The oneM2M Service Layer is organized as a set of common functions (or service capabilities), an instantiation of which is referred to as a Common Services Entity (CSE). FIG. 1 is a diagram that illustrates common functions of the one M2M service layer that are exposed via the Mca, Mcc and Mcn reference points as shown in FIG. 1.
The Mca reference point designates communication flows between an Application Entity (AE) 102 and a CSE 104, while the Mcc reference point designates communication flows between two CSEs 104 and 106 in the same M2M Service Provider domain. Communications across Mca and Mcc take place via paired Request/Response messages, wherein each request performs a specific RESTful operation (e.g., Create, Retrieve, Update, Delete) upon a resource hosted on the targeted CSE.
Mcc′ is used between CSEs located in the Infrastructure Domain of different M2M SPs. Mcn is used between a CSE 104 and an underlying Network Services Entity (NSE) 108 for services other than transport and connectivity.
In the oneM2M service layer, CSEs are hosted on architectural entities referred to as “nodes”. A node is a functional entity that contains a) one CSE and zero or more AEs, or b) one or more AEs.
FIG. 2 is a diagram of a oneM2M architecture that supports various types of node configurations. FIG. 2 is a simplified representation and does not reflect all possible configurations or relationships between entities.
FIG. 3 is a diagram that illustrates an initial set of common service functions (CSF) performed by the oneM2M CSE 302. A particular CSE implementation may not support every function, but a complete implementation can include all the functions in the illustration.
The Uniform Resource Identifier Generic Syntax is an internet construct consisting of a hierarchical sequence of five components (scheme, authority, path, query and fragment). FIG. 4 is a diagram that illustrates the scheme, authority and path components of the Uniform Resource Identifier Generic Syntax that are significant in oneM2M addressing.
Every entity in the oneM2M Service Layer is represented as a resource in the ROA architecture. Each instantiation of an AE or CSE on a Service Layer node is required to have a unique identifier. This unique identifier is used to derive an absolute Uniform Resource Identifier (URI) that represents the root (or base) address of the resource structure for that entity on its hosting CSE. Every resource within that structure must also be uniquely addressable via a Fully Qualified Domain Name (FQDN) URI having a path component that discretely identifies the target resource, in either a hierarchical or non-hierarchical fashion. The FQDN provides the network address of the node that contains the CSE hosting the resource and the path provides the precise location of the targeted resource on that node.
The following two example URI values address the same resource and illustrate the above principles, first with a hierarchical path structure and then with a non-hierarchical structure:                1) //CSE04.M2MSPabc.com/CSEBase01/alpha/container02/instance01        2) //CSE04.M2MSPabc.com/CSEBase01/resource12345678        
The underlined portion of URI #2 represents the address of the base resource structure for this example CSE, and also embodies the corresponding CSE identifier. The underlined portion of URI #1 represents the address of the resource structure for an application named “alpha”, and also embodies the corresponding AE identifier.
The resource structure associated with a CSE or AE also contains an attribute known as PoA (pointOfAccess) which holds routing information—generally one or more IP addresses—used to establish communication with the node hosting the CSE or AE. In order to target an AE (e.g., with a notification) it is necessary to first reach the CSE with which the AE is registered and then use the information in the AE-PoA attribute to address the request to the target AE.
The Service Layer Request/Response messages comprise an API that is carried over an application protocol to facilitate message movement between Service Layer entities. Because the Service Layer is situated between the applications which it serves and the lower network layers, it is often referred to as “middleware” as illustrated in FIG. 5.
There are numerous choices for binding at the Application Protocol Layer, though ETSI M2M and oneM2M both agreed on HTTP and CoAP initially. oneM2M has committed to support Message Queuing Telemetry Transport (MQTT) protocol binding as well—a choice made interesting by the contrast between the Service Layer's RESTful request/response (one-to-one) message pairs and the event-driven, publish/subscribe (one-to-many) MQTT protocol. Despite these differences, MQTT remains an attractive choice for M2M applications due to its extremely low protocol overhead and simple, efficient design.
The MQTT protocol was initially developed by IBM and Eurotech in the late 1990s; it was submitted to the OASIS standards body in 2013 for formal adoption (process ongoing) and further development. MQTT is a low overhead message queuing and transport protocol tailored for constrained devices and low bandwidth networks that is most famously deployed in the Facebook Messenger mobile app.
FIG. 6 is a diagram that illustrates the publish/subscribe (or client/server) model of MQTT. The core elements of MQTT are clients (which can be both publisher 602 and subscriber 604), servers (also referred to as brokers), sessions, subscriptions and topics.
FIG. 7 is a diagram that illustrates the elements of MQTT. Like HTTP, the MQTT protocol is asymmetric in that it distinguishes between two different roles: client 702 and server 704.
In MQTT terms, a Client 702 is a program or device that uses MQTT. It always establishes the Network Connection to the Server. A Client 702 can                Publish application messages that other Clients might be interested in.        Subscribe to request application messages that it is interested in receiving.        Unsubscribe to remove a request for application messages.        Disconnect from the Server.        
An MQTT Server 704 is an entity that accepts connections from Clients. Unlike HTTP it generally does not run any application logic, instead an MQTT Server 704 acts as an intermediary between Clients publishing application messages and the Clients which have subscribed to receive them.
Topics are the “Q” in MQTT—they are named message queues maintained by the server in order to link publishers with subscribers. An MQTT Client 702 assumes the role of publisher when it issues a PUBLISH message to an MQTT Server 704 (i.e., an instruction to deliver the opaque message payload to any Client subscribed to the supplied Topic Name), and assumes the role of subscriber when it issues a SUBSCRIBE message to the MQTT Server 704 (i.e., an instruction to receive any PUBLISH messages that match the supplied Topic Filter). A Topic Filter is an expression contained in a Subscription, to indicate an interest in one or more topics. A Topic Filter may include wildcard characters. PUBLISH messages are delivered with one of three QoS levels of assurance (at-most-once, at-least-once, exactly-once).
FIG. 8 is a diagram that illustrates sessions and subscriptions that represent two levels of attachment between a Client and a Server in MQTT. A session 801 and 802 is a stateful interaction (i.e., an active TCP/IP network connection) between a Client and a Server, and is identified by a unique Client Identifier. A session 801 and 802 can be established only by a Client sending a CONNECT message to a Server. Flags in the CONNECT, PUBLISH and SUBSCRIBE messages determine how session state is maintained if a session is disconnected.
Subscriptions 804 and 806 are the logical attachment of Clients to one or more topics (i.e., message queues) maintained by the Server. A subscription 806 is associated with only a single session 801, but it is possible to configure session state to be preserved in the event of session disconnection and to trigger delivery of stored subscribed messages when a subsequent session is established by the same Client. Thus, subscriptions may be “transient” (subscription 806) or “durable” (subscription 804).
A durable subscription 804 operating with the highest QoS level results in the Server operating in a store-and-forward mode for the associated Client (within the limits of the available storage capacity on the Server), whereas a transient subscription 806 paired with the lowest QoS level results in the Server operating in a pass-through mode for the associated Client.
MQTT network connections exist only between a Client 702 and a Server 704. From the perspective of an MQTT Client 702 all incoming Application Messages originate from the Server 704, and an MQTT Client 702 receiving an Application Message resulting from a subscription with the Server 704 might not even be able to reach the Client that originated that message at the network layer (e.g., IP). In that respect, the mechanism by which the Server 704 determines whether to forward an Application Message—matching the Topic Name against its list of subscriptions (i.e., Topic Filters)—treats the Topic Name field as a form of network address.
There is an intermediate step to consider, though, because the Server 704 does not associate a subscription directly with a network connection (e.g., an IP address). A subscription is associated with a session, and a session is associated with a Client Identifier (ClientID) that must be unique for every Client connecting to a Server. The ClientID is a UTF-8 encoded string of up to 65,535 bytes; however, a Server may restrict the length to no more than 23 UTF-8 encoded bytes. The ClientID mechanism allows for preservation of session state and enables store-and-forward capability (if desired).
Thus, the set of MQTT addressing associations is as follows:
Network ConnectionaddressClient IdentifierSubscription (Topic Filter)192.168.1.1Acme-Alarm-xyz/Anytown/Elm St./1234/#
“/” is the topic level separator used to divide Topic Name into hierarchical levels. “#” is the multi-level wildcard character that matches at any level(s) that follow. There is also a single-level wildcard character “+” that matches at only one level (not shown).
In this example, Acme Alarm Co. connected to an MQTT Server and established a session using its ClientID value of “Acme-Alarm-xyz”. It subscribed to Application Messages with a Topic Name corresponding to any match for that street address (1234 Elm St., Anytown). Acme Alarm has installed sensors and a network controller at this location and the controller is publishing Application Messages with the Topic Name “/Anytown/Elm St./1234/<sensorX>/<info>”. The Server compares incoming Application Messages to this subscription belonging to Acme and forwards any messages with a Topic match to the corresponding Network Connection address.
The MQTT V3.1.1 specification contains the following statement:                A single entity MAY conform as both an MQTT Client and MQTT Server implementation. For example, a Server that both accepts inbound connections and establishes outbound connections to other Servers MUST conform as both an MQTT Client and MQTT Server.        
The conformance statement from the MQTT specification (above) addresses implementations that make use of reserved protocol fields (generally needed to distinguish Server-Server connections from Client-Server connections). However, it is possible to interconnect MQTT Servers without the need to distinguish Server-Server connections and without violating the specification, as follows.
If only one of the Servers is configured in this manner then there can be only a one-way flow of traffic between them, toward the Server with the embedded Client functionality. This enables it to subscribe to other Servers and steer traffic toward itself, as shown in FIG. 9.
FIG. 9 is a diagram that illustrates a one way flow of messages between MQTT Servers. In FIG. 9, the MQTT Client 902 identified as “S1/C1” has previously sent a SUBSCRIBE message to Server S1, causing Server S1 to establish a topic queue with the Topic Filter “S1/C1/#”. Subsequently, any Publish message arriving at Server S1 with a Topic Name field in which the first five characters are equal to “S1/C1” will be forwarded to ClientS1/C1 902.
The “Publish” and “Subscribe” functions shown in the standalone Clients indicate which role (publisher or subscriber) the Client has when it handles the message shown in the flow.
The SUBSCRIBE message sent by the embedded Client function 904 in Server S1 to Server S2 causes Server S2 to establish a topic queue with the Topic Filter “S1/#”. This is the action that forms the (one-way) connection between the two Servers. Subsequently, any PUBLISH message arriving at Server S2 with a Topic Name field in which the first two characters are equal to “S1” will be forwarded to Server S1. In this way a Client connected to Server S1 can be reached by a Client connected to either Server S1 or Server S2 (or any other Server with which Server S1 establishes a connection).
The connection can be torn down at any time by the Client 902 in Server S1 sending a DISCONNECT message to Server S2; the corresponding CONNECT message (prior to SUBSCRIBE) is not shown but is assumed. Note that Server S2 has no indication that the connection from the Client 902 in Server S1 is associated with another Server; Server S1 appears like any other Client to Server S2 (at the protocol level).
FIG. 10 is a diagram that illustrates bidirectional traffic flow between MQTT servers and Clients connected to either Server. In this case, both Clients S1/C1 and S2/C1 have previously sent a SUBSCRIBE message to their respective Servers, causing those Servers to establish a topic queue with the Topic Filter shown. The SUBSCRIBE messages sent by the embedded Client function in each Server cause the receiving Server to establish a topic queue with a Topic Filter that points to the originating Server+Client combination. Together this pair of actions forms a bidirectional connection between the two Servers—a Client connected to one Server can reach a Client connected to the other Server, and vice versa. Request/response messaging is thus made possible between Clients connected to different Servers.
It is important to note that the SUBSCRIBE messages sent between the Servers are independent of one another (i.e., one does not trigger the other at the protocol level). The Server receiving a SUBSCRIBE message has no way of being signaled in the protocol that the message is associated with a Client-enabled Server rather than a pure Client—at least not if the implementation is to remain standard-compliant. A simplistic approach in this scenario would be to establish static connections between Servers as part of system initialization, with each Server preconfigured with the information needed to establish its connections upon startup.
Alternatively, logic embedded in a standalone Server implementation could treat specific patterns in the Topic Filter field of the SUBSCRIBE message as a marker for a Server-originated message and use that marker as a signal to initiate a companion SUBSCRIBE message in the return direction. Upper layer logic with integrated Server functionality could also trigger and initiate connections dynamically on an as-needed basis.
So long as a managed hierarchical—or URI-like—structure is administered in the Topic Name space and global uniqueness of the values/addresses used to populate the Topic Name field is maintained, then continual bidirectional communication between Clients connected to cooperating Servers is possible.
oneM2M is developing a Technical Specification for MQTT Protocol Binding. Several configuration alternatives are shown in the Technical Specification with respect to placement of the MQTT Server within the oneM2M architecture, but all of these configurations share the characteristic that the MQTT Server is a functionally and logically distinct entity that communicates only with MQTT Clients and does not communicate with other MQTT Servers in the oneM2M Service Layer.
FIG. 11 is a diagram that illustrates a single MQTT Server 1102 within a Service Provider domain that maintains connections to every AE 1104 and CSE 1106 and 1108. This the most straightforward configuration.
FIGS. 12A and 12B illustrate the use of multiple MQTT servers in a oneM2M embodiment. An alternative to a single, monolithic MQTT Server in the Infrastructure Domain is to deploy multiple MQTT Servers at Middle Nodes and support MQTT closer to the network edge (only over the Mca reference point). Another alternative would be to have one (or possibly more) MQTT network(s) carrying Mca traffic in the Field Domain and a separate MQTT network carrying Mcc traffic back to the Infrastructure Domain. In this scenario interworking between the independent MQTT networks would be performed by the oneM2M Service Layer.
FIG. 13 illustrates a oneM2M embodiment with a MQTT server 1302. Applying the concept of a single MQTT Server (FIG. 11) to the oneM2M Architecture Configurations (FIG. 2) yields the illustration in FIG. 13. Traffic between any two Service Layer entities must flow through the MQTT Server 1302, and communication between any two Service Layer entities is not possible unless they are both connected to that MQTT Server 1302 (or unless the Service Layer provides additional logic to pass traffic from MQTT-connected entities to non-MQTT-connected entities).
The configuration shown in FIG. 13 is the focal point for current development work. It is possible to add MQTT Servers and redistribute the Service Layer entities among them (e.g., place MQTT Servers in the Field Domain as suggested in FIG. 12), but any change of the MQTT Server to which a specific MQTT Client connects would require providing the network address of the new Server to the Client beforehand. This is because MQTT lacks a mechanism for Clients to discover Servers, yet a Client always initiates the connection to a Server (so the network address must be available to the Client before a network connection can be made).